home *** CD-ROM | disk | FTP | other *** search
Text File | 1993-06-16 | 107.8 KB | 3,523 lines |
-
-
-
-
-
-
- Network Working Group W A Simpson
- Internet Draft Daydreamer
- expires in six months June 1993
-
-
-
- SIP System Discovery
-
-
-
- Status of this Memo
-
- This memo is the product of the SIP Working Group of the Internet
- Engineering Task Force (IETF). Comments on this memo should be
- submitted to the sip@caldera.usc.edu mailing list.
-
- Distribution of this memo is unlimited.
-
- This document is an Internet Draft. Internet Drafts are working
- documents of the Internet Engineering Task Force (IETF), its Areas,
- and its Working Groups. Note that other groups may also distribute
- working documents as Internet Drafts. Internet Drafts are draft
- documents valid for a maximum of six months. Internet Drafts may be
- updated, replaced, or obsoleted by other documents at any time. It
- is not appropriate to use Internet Drafts as reference material or to
- cite them other than as a ``working draft'' or ``work in progress.''
- Please check the 1id-abstracts.txt listing contained in the
- internet-drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net,
- nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the
- current status of any Internet Draft.
-
- Abstract
-
- This document specifies ICMP messages for the identification and
- location of adjacent SIP systems. This is intended to replace ARP,
- ICMP Router Advertisement, ICMP Redirect, ICMP Information, ICMP
- Mask, and OSPF Hello in the SIP environment. There are also elements
- of the OSI ES-IS and IS-IS Hello.
-
-
-
-
-
-
-
-
-
-
-
-
-
- Simpson expires in six months [Page i]
- DRAFT system discovery June 1993
-
-
- 1. Terminology
-
- The following terms have a precise meaning when used in this
- document:
- system a device that implements the Internet Protocol, IP [9].
-
- intermediate-system
- a system that forwards datagrams, as specified in [2].
- Often called a router or gateway. This does not include
- systems that, though capable of forwarding, have that
- capability turned off. Nor does it include systems that
- do forwarding only as required to obey Source Route
- options.
-
- end-system any system that is not acting as an intermediate-system.
- Often called a host.
-
- dumb the minimal implementation. This is not meant in a
- perjorative sense. It is intended that every mechanism
- be defined in such a way that it is implementable on a
- minimal system.
-
- smart an improved implementation, possibly requiring more
- internal resources, while using less external resources.
-
- multicast unless otherwise qualified, means the use of either IP
- multicast [4] or IP broadcast [6] service.
-
- link a communication facility or medium over which systems
- can communicate at the link layer; that is, the protocol
- layer immediately below IP. The term "physical network"
- has sometimes been used (imprecisely) for this.
- Examples of links are LANs (possibly bridged to other
- LANs), wide-area store-and-forward networks, satellite
- channels, and point-to-point circuits.
-
- multicast link a link over which IP multicast or IP broadcast service
- is supported. This includes broadcast media such as
- LANs and satellite channels, single point-to-point
- circuits, and some store-and-forward networks such as
- SMDS networks [8].
-
- interface a system's attachment point to a link. It is possible
- (though unusual) for a system to have more than one
- interface to the same link.
-
- multicast interface
- an interface to a multicast link; that is, an interface
-
-
-
- Simpson expires in six months [Page 1]
- DRAFT system discovery June 1993
-
-
- to a link over which IP multicast or IP broadcast
- service is supported.
-
- identifier uniquely identifies each interface; a single interface
- may have more than one such identifier.
-
- primary identifier
- uniquely identifies each system; only one such
- identifier is used, to simplify discovery of neighbors.
-
- subnet either a single link of a subnetted IP network [7] or
- a single non-subnetted link.
-
- prefix the part of an identifier which may be used for routing
- to a particular subnet, defined by logically ANDing with
- its assigned subnet mask. More than one subnet prefix
- may identify the same link.
-
- zone the part of a special identifier which indicates a
- unique subnet within an administrative domain.
-
- neighbor having an identifier belonging to the same subnet.
-
-
- 2. Criteria
-
- Historically, the methods for discovery of the next-hop evolved
- separately from those for location of neighbors and auto-
- configuration of systems. With the advent of SIP, the old techniques
- must be re-implemented, usually due to larger field sizes.
- Unfortunately, older implementations frequently did not take proper
- care in differentiating existing variable field lengths, version
- numbers, and new types of messages. Therefore, the techniques used
- for SIP are required to be distinguishable from previous versions.
-
- None of the current protocols are readily extensible. While some
- have the ability to change in simple terms, such as larger addresses,
- none were designed to add new kinds of information to be carried in
- the same packet.
-
- This can be viewed is an opportunity to design a uniform and coherent
- method for accomplishing these goals, rather than a liability.
-
- Through prior experience, the following criteria were established, in
- order of relative importance. It is understood that many of these
- criteria may conflict, and require numerous tradeoffs.
-
-
-
-
-
- Simpson expires in six months [Page 2]
- DRAFT system discovery June 1993
-
-
- Multicast support
-
- All SIP systems are required to support multicast.
-
- This is the primary technique for distinguishing the new messages.
- Older systems will ignore multicast messages at the link layer.
-
- There are numerous other advantages to using multicast for the new
- messages. In particular, when compared to broadcast, reduced
- overhead for processing messages which are not ultimately intended
- for the local system.
-
- Not all media supports multicast. Since multicast is directly
- supported by the SIP header, this technique will work even when
- using link-layer broadcast, or link-layer unicast to each
- recipient.
-
- Reduced net traffic
-
- Currently, there are separate packets sent for media address
- resolution, router discovery, and the Hello protocols for the
- various routing algorithms. Since much of the same information is
- contained in each of these packets, it would be helpful to combine
- the functions in a single packet where possible.
-
- Also, the most common next-hop resolution protocol, the Address
- Resolution Protocol (ARP), requires an additional two packets at
- the beginning of each connection. The Request is sent, a Reply is
- received, and then the first datagram can be sent to the next-hop.
- This causes a significant amount of traffic, and considerable
- latency in establishing a connection.
-
- Several alternative methods were proposed:
-
- 1) The ISO solution (ES-IS) eliminates some of these problems.
- Each end-system and intermediate-system sends Hellos on a
- periodic basis. Every system must remember all of the media
- addresses for the other systems on the local network. This
- does eliminate the latency of ARP, at the expense of many
- additional packets sent on a regular basis, and a large
- amount of storage overhead in each system.
-
- 2) The first packet destined for an unknown system may be sent
- to the all-systems multicast, or to a media multicast based
- on a hash function of the destination. The appropriate
- system accepts the packet, and sends a redirect indicating
- the appropriate media address to be used for future packets.
- This reduces the traffic from 3 to 2 packets at the
-
-
-
- Simpson expires in six months [Page 3]
- DRAFT system discovery June 1993
-
-
- beginning of a connection, and eliminates the latency, as
- the discovery packet sent is also the data packet. The
- destination identifer in the network header will be unicast,
- while the media address will be multicast. Intermediate-
- systems would require extra intelligence to recognize those
- packets destined beyond the local link, while multi-homed
- end-systems require that capability already. Also, this
- method is not extensible to include other information useful
- in mobile environments.
-
- 3) Using advertisements for the (fewer) intermediate systems,
- and an ARP-like protocol for those end-system connections
- that are on the local media. For those packets which are
- clearly destined off the local media, the packet can be sent
- directly to the appropriate intermediate system. When most
- of the traffic is between systems that are not on the same
- local media, this is very efficient. When most of the
- traffic is between end-systems on the local media (client-
- server), the extra discovery packets will be rare.
-
- The solution that is detailed here is a combination of the best
- features of the preceding techniques.
-
- Intermediate-systems advertise their locations. When an
- intermediate-system needs the location of an end-system, it
- requests the location of the end-system, and the end-system
- replies. Knowledge about end-systems is concentrated in the
- intermediate-systems, but only for the systems that are actually
- communicating.
-
- End-systems send all datagrams directly to the intermediate-
- systems. If there is a more direct path to the end-system,
- because it is directly accessible on the local link or another
- intermediate-system would be more appropriate, the intermediate-
- system issues a redirect.
-
- Also, by carrying media addresses within the advertisements and
- redirect packets, a further ARP-like query/response can be avoided
- entirely.
-
- Low storage overhead
-
- It is desirable that systems require as little storage overhead as
- possible. In particular, mobile systems often have significantly
- reduced processing power and memory.
-
- An end-system need only retain information for those end-systems
- with which it is directly communicating.
-
-
-
- Simpson expires in six months [Page 4]
- DRAFT system discovery June 1993
-
-
- This design requires sufficient storage in an end-system for
- information about at least one intermediate-system. In addition,
- storage is required for at least one location of each service
- (such as a domain name server) which is used.
-
- An intermediate-system may require more processing power and
- memory. Participation in routing protocols requires the knowledge
- of every neighboring intermediate-system.
-
- When subnet prefix-routing is in use, it is not necessary for an
- intermediate-system to determine the location of an end-system
- until traffic for the end-system arrives. If prefix-routing is
- not used, particularly in radio and mobile environments, the
- location of each reachable end-system must be continuously
- retained.
-
- Auto-configuration
-
- It would be highly desirable that the connection procedures for a
- configuring a new system are reduced to the minimal set of "plug
- it in, turn on the power, and run".
-
- - Each system, or more precisely each interface, should be
- assigned an identifier, within the number space assigned to the
- local subnet.
-
- - Each system should be assigned a name within the local domain.
- The name, and the associated identifiers, should be registered
- in the local domain name server.
-
- - The system should discover the external routes provided by the
- intermediate-systems attached to the local subnet, so that it
- can exchange packets with remote systems.
-
- - The system should discover the location of servers that it
- needs for configuration, loading, dumping, printing, and other
- services.
-
- In evaluating previous experience with autoconfiguration
- procedures, the following constraints were determined:
-
- 1) It is not possible to embed an IEEE-802 component within
- every SIP identifier, since the remaining prefix would be
- too small for global routing. Using the 48-bit IEEE-802
- number to identify one system within a local network that is
- not designed to accomodate more than a few hundred systems
- is considerable overkill. It may be worthwhile to use the
- address during initial configuration.
-
-
-
- Simpson expires in six months [Page 5]
- DRAFT system discovery June 1993
-
-
- 2) Random identifier assignments are to be avoided. They do
- not scale well to large networks, are difficult to track and
- manage, and lead to administrative confusion. Relying on
- broadcast collision resolution procedures for avoiding
- duplicate assignments results in conflicts when systems
- occupy partitioned subnets, or are frequently powered down
- or taken off-line.
-
- 3) Reassignment of identifiers should be transparent to the
- human users. In particular, renumbering, and assignment of
- alias identifiers as a mobile system moves should be
- automatic.
-
- 4) End-system users should not be concerned with routing
- prefixes, or the routing methods extant on the local
- network. When used, such prefixes should be automatically
- determined, and dynamic changes should propagate
- automatically.
-
- 5) It is important to allow users to choose a system name which
- is memorable and comfortable to them. The name should be
- automatically registered, and changes to the associated
- identifers should be maintained automatically.
-
- This design handles initial self-identification and propagation of
- changes in identification. Other aspects of configuration, such
- as loading the operating system and environment, and additional
- facilities and servers for registration, are specified elsewhere.
-
- Mobility support
-
- This is sometimes considered a subset of the above, as related to
- dynamically changing addresses while moving. Other systems must
- be notified of the changes.
-
- In addition, the "hidden transmitter" problem is considered (you
- can hear another system, it can't hear you, but there is a path to
- a third system which it can hear, completing the circuit). This
- is not well supported in any of the past protocols.
-
- Although basic support for mobility is provided, descriptions of
- additional facilities and servers are specified elsewhere.
-
- Black hole detection
-
- In determining whether the next-hop system is still available,
- there is a basic tradeoff between frequent queries and resources
- used. This design trades fewer queries against more information
-
-
-
- Simpson expires in six months [Page 6]
- DRAFT system discovery June 1993
-
-
- within each query and response.
-
- Explicit holding times are used to limit the exposure to black
- holes. The times may be dynamically shortened by the responsible
- system when a resource is critical, or when the system is actively
- moving.
-
- Media independence
-
- There are many instances where system discovery is accomplished
- differently over different media, such as point-to-point versus
- broadcast versus Large Public Data Networks. This design places
- the system discovery above the network layer, where it enjoys
- greater independence. It also encompasses media level redirects
- between multiple logical subnets on the same physical media.
-
- There are difficulties with carrying media addresses within
- packets, especially in the presence of multi-media bridges.
- Rather than allowing translation by bridges in the path, this
- design exercizes control at the destination system, and requires
- all such media addresses to be in canonical form,
-
- Optimal route determination
-
- This is essentially a superset of next-hop discovery, combined
- with resource reservation and possible policy considerations, and
- the ability to redirect traffic under changing conditions. This
- is not well supported in any of the past protocols.
-
- To balance system overhead against network traffic, this design
- attempts to adapt to a continuum of system capabilities. Dumb
- end-systems may simply send packets to a default intermediate-
- system, and be redirected to the correct next-hop by more capable
- intermediate-systems. Smarter end-systems learn sufficient
- information to make informed choices.
-
- Simplicity
-
- All of the above desires, and they want to keep it simple, too.
- This design reduces the number of packet types which must be
- supported in a pure SIP system, and reduces the number of systems
- which recognize and respond to each type. The extensions are
- designed with 32 and 64 bit boundaries for efficient processing.
-
-
-
-
-
-
-
-
- Simpson expires in six months [Page 7]
- DRAFT system discovery June 1993
-
-
- 3. Design Overview
-
- This proposal describes two packets, not much different from those
- already deployed. These familiar forms are re-packaged to join
- common functions into the same packet to reduce traffic, and are
- designed to be more extensible in the future.
-
- In order to foster media independence, the packets are part of ICMP,
- which allows the protocols to be used over broadcast, multicast,
- partial-mesh, and point-to-point media. This is similar to the
- positioning of ES-IS.
-
- The Where-Are-You solicitation is used to find other systems, and
- associated resources and services. General solicitations are sent
- when a system interface is initialized. Specific solicitations are
- sent when one system is ready to communicate with another particular
- system.
-
- The I-Am-Here advertisement is the answer to the Where-Are-You
- solicitation. Advertisements are also sent on a periodic basis to
- indicate special resources and services. Periodic advertisements
- from a few commonly requested systems result in less traffic than
- repeated solicitations from many systems.
-
- Each advertisement includes a lifetime field, specifying the maximum
- length of time that the advertisements are to be considered valid in
- the absence of further advertisements. This ensures that other
- systems eventually forget about systems that become unreachable,
- whether that is because the system has failed, or it no longer
- provides the advertised service.
-
- Each message contains "optional" extensions, designed to allow
- flexibility and extensibility.
-
- One of the common extensions is the media address. Each message
- contains enough information to return a reply directly to the sender,
- without additional location traffic.
-
- Another common extension is a list of the intermediate-systems which
- have been heard. This allows intermediate-systems to build a map of
- the paths between intermediate-systems, and between intermediate-
- systems and end-systems. This is designed to be used by most
- commonly deployed routing protocols. This also solves the "hidden
- transmitter" problem, when used together with the well-known link-
- state class of routing protocols.
-
- Several methods of routing are supported.
-
-
-
-
- Simpson expires in six months [Page 8]
- DRAFT system discovery June 1993
-
-
- 3.1. System Identification
-
-
- Zone
-
- A Zone is defined to be a collection of links which may be
- accessed as the same next-hop. A Zone is usually a single link,
- or a collection of bridged links. When a single intermediate-
- system is connected to multiple point-to-point links, these links
- may be collected into a single zone.
-
- The Zone number is a fixed size. The value 0 is only used to
- indicate the local zone. The values 1 through 255 indicate each
- zone within an administrative domain.
-
- Zone numbers may be combined with an interface media address to
- make a locally significant identifier. This is useful for initial
- configuration and local communication within the administrative
- domain. These identifiers may be routed in a similar manner to
- prefix-routed subnets.
-
- The generation of these local identifiers depends upon the
- availability of a registered unique number, such as an IEEE-802
- number. When there is no IEEE-802 number to be found anywhere in
- the machine, such as when the machine is connected exclusively to
- point-to-point links, an external link-level mechanism MUST be
- used to negotiate a unique identifier. Such a mechanism is beyond
- the scope of this document.
-
- Prefix
-
- A Prefix is similar to a Zone, in that it identifies a collection
- of links which may be accessed as the same next-hop. The Prefix
- may indicate a single zone, a collection of zones, an entire
- administrative domain, or a collection of administrative domains.
-
- The Prefix is variable in size. The Prefix Size ranges from 1 to
- 62. The value of 63 cannot be used, since at least 2 bits of the
- SIP 64-bit identifier are reserved to identify a particular
- system.
-
- Prefix-routed subnet identifiers are supported for addressing
- globally connected networks in the metropolitan and/or provider
- addressing models.
-
- End-Point Identifiers
-
- End-Point identifiers, or any other globally unique identifier,
-
-
-
- Simpson expires in six months [Page 9]
- DRAFT system discovery June 1993
-
-
- may be used with future routing techniques. An End-Point
- Identifier is indicated as having a Prefix Size of 0. A mobile
- system may be treated as having an End-Point Identifier when it
- appears in a prefix-routed subnet, since it will not have the same
- prefix as other systems in the subnet.
-
- Facilities are provided for exchange of redirects and translation
- between the various forms of identifiers.
-
-
- 3.2. Multicast Support
-
- Every SIP system MUST join the all-systems multicast group on all
- interfaces on which the system supports multicast.
-
- Every SIP intermediate-system MUST also join the all-routers
- multicast group.
-
- Every SIP end-system which offers a particular service MUST also join
- the multicast group for that service. Intermediate-systems do not
- join the service multicast group, as their services are discovered
- under a separate process.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Simpson expires in six months [Page 10]
- DRAFT system discovery June 1993
-
-
- 4. Intermediate-System Discovery
-
- Before an end-system can send datagrams beyond its directly attached
- link, it must discover the location of at least one operational
- intermediate-system on that link. This is accomplished through
- intermediate-system advertisement messages.
-
- The intermediate-system advertisements also serve to indicate zone
- and subnet prefixes for each link, and to establish neighbor
- relationships with other intermediate-systems.
-
- Each intermediate-system periodically sends the I-Am-Here message to
- advertise its forwarding capability. End-systems and intermediate-
- systems discover the location of their neighboring intermediate-
- systems simply by listening for the advertisements. This eliminates
- the need for manual configuration of intermediate-system addresses
- and is independent of any specific routing protocol.
-
- The advertisement messages do not constitute a routing protocol,
- although they might be used by a routing protocol to build a map.
- They enable systems to discover the existence of neighboring
- intermediate-systems, but not necessarily which intermediate-system
- is best to reach a particular destination. If a system chooses a
- poor intermediate-system for a particular destination, it should
- receive a redirect from that intermediate-system.
-
- However, the advertisements often contain sufficient information to
- make a good choice of first-hop. This may be important for choosing
- among intermediate-systems which are participating in a security
- group or policy-based routing.
-
-
- 4.1. Solicitations
-
- Every SIP end-system MUST implement Intermediate-System Solicitation.
-
- When any end-system starts up, it MUST send the Where-Are-You
- solicitation to prompt the advertisement of intermediate-systems.
- This is also used by the intermediate-systems to construct a map of
- accessible end-systems, to discover partitions in the local subnet,
- and to support mobile systems.
-
- If (and only if) no advertisements from neighboring intermediate-
- systems are forthcoming, the end-system MAY retransmit the Where-
- Are-You a small number of times, but then MUST desist from sending
- more solicitations.
-
- Any intermediate-systems that subsequently start up, or that were not
-
-
-
- Simpson expires in six months [Page 11]
- DRAFT system discovery June 1993
-
-
- discovered because of packet loss or temporary link partitioning, are
- eventually discovered by reception of their periodic (unsolicited)
- advertisements. Links that suffer high packet loss rates or frequent
- partitioning are accommodated by increasing the rate of
- intermediate-system advertisements, rather than increasing the number
- of solicitations that end-systems are permitted to send.
-
-
- 4.1.1. Constants
-
- MAX_SOLICITATIONS 3 transmissions
-
- MAX_SOLICITATION_DELAY 1 second
-
- SOLICITATION_INTERVAL 3 seconds
-
-
- 4.1.2. Implementation
-
- The intermediate-system solicitation is sent to the all-routers
- multicast, with the scope set to local.
-
- An end-system is required to transmit up to MAX_SOLICITATIONS Where-
- Are-You messages from any of its interfaces after any of the
- following events:
-
- - The interface is initialized at system startup time.
-
- - The interface is reinitialized after a temporary interface failure
- or after being temporarily disabled by system management.
-
- - The system has its forwarding capability turned off by system
- management.
-
- If a system chooses to send a solicitation after one of the above
- events, it should delay transmission for a random amount of time
- between 0 and MAX_SOLICITATION_DELAY. This serves to alleviate
- congestion when many systems start up on a link at the same time,
- such as might happen after recovery from a power failure.
-
- It is recommended that systems include some unique value (such as one
- of their interface or link-layer identifiers) in the seed used to
- initialize their pseudo-random number generators. Although the
- randomization range is specified in units of seconds, the actual
- randomly-chosen value should not be in units of whole seconds, but
- rather in units of the highest available timer resolution.
-
- The small number of retransmissions of a solicitation, which are
-
-
-
- Simpson expires in six months [Page 12]
- DRAFT system discovery June 1993
-
-
- permitted if no advertisement is received, should be sent at
- intervals of SOLICITATION_INTERVAL seconds, without further
- randomization.
-
- Upon receiving a valid advertisement from any intermediate-system
- subsequent to one of the above events, the system MUST NOT send any
- solicitation on that interface (even if none have been sent yet)
- until the next time one of the above events occurs.
-
-
- 4.1.3. Receipt
-
- An end-system MUST silently discard any received Intermediate-System
- Solicitation messages.
-
- An intermediate-system MUST silently discard any received
- Intermediate-System Solicitation messages that do not satisfy the
- following validity checks:
-
- - ICMP Checksum is correct.
-
- - ICMP length (derived from the payload length) is 16 or more
- octets.
-
- - Source Address is either 0 or the identifier of a neighbor (an
- identifier that matches one of the intermediate-system's own
- identifiers on the arrival interface under the prefix mask
- associated with that identifer, or the zone associated with that
- interface).
-
-
- 4.2. Advertisements
-
- Every SIP intermediate-system MUST implement Intermediate-System
- Advertisements.
-
- The intermediate-system advertisements include such important
- information as the media address to access the system, other subnets
- directly accessible through the system, services available through
- the system, and neighboring intermediate-systems heard.
-
- Identifiers
-
- Each intermediate-system advertisement includes one or more
- identifier fields. These indicate the identifiers which are
- presently in use for each interface of the intermediate-system.
-
-
-
-
-
- Simpson expires in six months [Page 13]
- DRAFT system discovery June 1993
-
-
- Zone
-
- Each advertised identifier includes a zone field. The value
- ranges from 0 to 255, and indicates a subnet number which is
- unique to the administrative domain. A value of zero indicates
- that no zone number has been assigned. It may be combined with an
- interface media address to make a locally significant identifier.
-
- If all advertised zone values are zero, then zone routing is not
- available beyond that link. This does not prevent the use of
- locally significant identifiers for communication with other
- systems on the local link.
-
- Prefix Size
-
- Each advertised identifier includes a prefix size field. The
- value ranges from 0 to 62, and indicates the number of bits in the
- Identifier which define the prefix mask for the link. A value of
- zero indicates an end-point identifier. When the value is not
- zero, the identifier may be used to discern prefix-routed subnet
- mapping.
-
- If all advertised prefix values are zero, then subnet prefix-
- routing is not in use on that link.
-
- Preference
-
- Each advertised identifier includes a preference field. This is
- used to choose a default intermediate-system for the first-hop
- when the end-system has not yet been redirected or configured to
- use a specific intermediate-system for a particular destination.
- The end-system is expected to choose from those intermediate-
- systems that have the highest preference level for the best
- prefix-routing match. When there is no match, or prefix-routing
- is not in use, the preference value is used alone.
-
- A network administrator can configure intermediate-system
- preference levels to encourage or discourage the use of particular
- intermediate-systems as the default first-hop. The use of
- separate preferences per prefix allows the choice of different
- intermediate-systems for each prefix, when there are multiple
- prefixes in use for the same link. This may be useful where
- multiple organizations share resources.
-
- [I am not sure how this works when there are multiple identifiers
- per end-system interface.]
-
- The preference value is not the same as the "metric" used in many
-
-
-
- Simpson expires in six months [Page 14]
- DRAFT system discovery June 1993
-
-
- routing protocols. It is used only by end-systems in determining
- the default first-hop, rather than by intermediate-systems in
- choosing a link for transit traffic. The values are not additive.
- Therefore, the range of values is smaller, and a higher value
- indicates a higher preference.
-
- It should be understood that preference levels learned from
- intermediate-system advertisements do not affect any system's
- cached route entries. For example, if a system has been
- redirected to use a particular intermediate-system to reach a
- specific destination, it continues to use that intermediate-system
- for that destination, even if it discovers another intermediate-
- system identifier with a higher preference level. Preference
- levels influence the choice of intermediate-system only for a
- destination for which there is no cached or configured route, or
- whose cached route points to an intermediate-system that is
- subsequently determined to be unreachable.
-
-
- 4.2.1. Constants
-
- MAX_INITIAL_ADVERTISEMENTS 3 transmissions
-
- MAX_INITIAL_ADVERT_INTERVAL 16 seconds
-
- MAX_RESPONSE_DELAY 2 seconds
-
-
- 4.2.2. Configuration
-
- An intermediate-system MUST allow the following variables to be
- configured by system management. Default values are specified which
- make it unnecessary to re-configure these variables in most cases.
-
- For each interface:
-
- MaxAdvertisementInterval
-
- The maximum time (in seconds) allowed between sending
- intermediate-system advertisements from the interface. Must be no
- less than 4 seconds and no greater than 1800 seconds.
-
- Default: 600 seconds
-
- MinAdvertisementInterval
-
- The minimum time (in seconds) allowed between sending unsolicited
- intermediate-system advertisements from the interface. Must be no
-
-
-
- Simpson expires in six months [Page 15]
- DRAFT system discovery June 1993
-
-
- less than 1 second and no greater than MaxAdvertisementInterval.
-
- Default: 0.75 * MaxAdvertisementInterval
-
- AdvertisementLifetime
-
- The value (in seconds) to be placed in the Lifetime field of
- intermediate-system advertisements sent from the interface. Must
- be no less than MaxAdvertisementInterval and no greater than 9000
- seconds.
-
- Default: 3 * MaxAdvertisementInterval
-
-
- For each of the identifiers of each interface:
-
- Advertise
-
- A flag indicating whether or not the identifier is to be
- advertised.
-
- Default: TRUE
-
- PreferenceLevel
-
- The preferability of the interface as a default intermediate-
- system choice, relative to other intermediate-system interfaces
- serving the same prefix on the same link.
-
- Values are in the range 0 to 255. Higher values mean more
- preferable. The minimum value 0 is used to indicate that the
- identifier, even though it may be advertised, is not to be used by
- neighboring end-systems as a default intermediate-system address.
-
- Default: 1
-
- It is useful to configure an identifier with a preference level of 0
- (rather than simply setting its Advertise flag to FALSE) when
- advertisements are being used for "black hole" detection. In
- particular, an intermediate-system that is to be used to reach only
- specific destinations could advertise a preference level of 0 (so
- that neighboring end-systems will not use it as a default
- intermediate-system for reaching arbitrary destinations) and a non-
- zero lifetime (so that neighboring end-systems that have been
- redirected or configured to use it can detect its failure by timing
- out the reception of its advertisements).
-
- It has been suggested that, when the preference level of an
-
-
-
- Simpson expires in six months [Page 16]
- DRAFT system discovery June 1993
-
-
- identifier has not been explicitly configured, an intermediate-system
- could set it according to the metric of the intermediate-system's
- "default route" (if it has one), rather than defaulting as suggested
- above. Thus, an intermediate-system with a better metric for its
- default route would advertise a higher preference level for its
- identifier. (Note that routing metrics that are encoded such that
- "lower is better" would have to be inverted before being used as
- preference levels in intermediate-system advertisement messages.)
- Such a strategy might reduce the amount of redirect traffic on some
- links by making it more likely that an end-system's first choice for
- reaching an arbitrary destination is also the best choice.
-
- On the other hand, redirect traffic is rarely a significant load on a
- link, and there are some cases where such a strategy would result in
- more redirect traffic (on links from which the most frequently chosen
- destinations are best reached via intermediate-systems other than the
- one with the best default route). Also, since the routing algorithms
- learn of neighboring intermediate-systems from the advertisements,
- and the default routes are learned from the routing algorithms, the
- calculated preference may be unstable from time to time. This
- document makes no recommendation concerning this issue, and
- implementors are free to try such a strategy, as long as they also
- support static configuration of preference levels as specified above.
-
-
- 4.2.3. Implementation
-
- The intermediate-system advertisement is sent to the all-systems
- multicast, with the scope set to local.
-
- The term "advertising interface" refers to any functioning and
- enabled interface that has at least one identifier whose configured
- Advertise flag is TRUE.
-
- From each advertising interface, the system MUST transmit periodic
- I-Am-Here messages.
-
- CONTROVERSIAL:
-
- When an intermediate-system discovers that it is receiving its own
- advertisements, that is an indication that it has more than one
- interface on same link. The system MUST choose only one
- advertising interface for each link. Identifiers associated with
- the remaining interfaces on the same link are indicated with the
- Other-Identifier extension. Redirect is used to move specific
- traffic to the alternate interfaces.
-
- An intermediate-system MAY proxy for the identifers of other
-
-
-
- Simpson expires in six months [Page 17]
- DRAFT system discovery June 1993
-
-
- systems, using the Other-Identifier extension. This SHOULD only
- be used when the intermediate-system is translating to another
- network-layer protocol format.
-
- The advertisements are not strictly periodic. The interval between
- subsequent transmissions is randomized to reduce the probability of
- synchronization with the advertisements from other intermediate-
- systems on the same link. This is done by maintaining a separate
- transmission interval timer for each advertising interface. Each
- time an advertisement is sent from an interface, that interface's
- timer is reset to a uniformly-distributed random value between the
- configured MinAdvertisementInterval and MaxAdvertisementInterval.
- Expiration of the timer causes the next advertisement to be sent, and
- a new random value to be chosen.
-
- It is recommended that intermediate-systems include some unique value
- (such as one of their interface or link-layer addresses) in the seed
- used to initialize their pseudo-random number generators. Although
- the randomization range is configured in units of seconds, the actual
- randomly-chosen values should not be in units of whole seconds, but
- rather in units of the highest available timer resolution.
-
- For the first few advertisements sent from an interface (up to
- MAX_INITIAL_ADVERTISEMENTS), if the randomly chosen interval is
- greater than MAX_INITIAL_ADVERT_INTERVAL, the timer should be set to
- MAX_INITIAL_ADVERT_INTERVAL instead. Using this smaller interval for
- the initial advertisements increases the likelihood of an
- intermediate-system being discovered quickly when it first becomes
- available, in the presence of possible packet loss.
-
- An interface may become an advertising interface at times other than
- system startup, as a result of recovery from an interface failure or
- through actions of system management such as:
-
- - enabling the interface, if it had been administratively disabled
- and it has one or more identifiers whose Advertise flag is TRUE,
-
- - enabling SIP forwarding capability (changing the system from an
- end-system to an intermediate-system), when the interface has one
- or more identifiers whose Advertise flag is TRUE,
-
- - setting the Advertise flag of one or more of the interface's
- identifiers to TRUE (or adding a new identifier with a TRUE
- Advertise flag), when previously the interface had no identifier
- whose Advertise flag was TRUE.
-
- In such cases, the intermediate-system must commence transmission of
- periodic advertisements on the new advertising interface, limiting
-
-
-
- Simpson expires in six months [Page 18]
- DRAFT system discovery June 1993
-
-
- the first few advertisements to intervals no greater than
- MAX_INITIAL_ADVERT_INTERVAL. In the case of an end-system becoming
- an intermediate-system, the system must also join the all-routers
- multicast group on all interfaces on which the intermediate-system
- supports multicast (whether or not they are advertising interfaces).
-
- An interface MAY also cease to be an advertising interface, through
- actions of system management such as:
-
- - shutting down the system,
-
- - administratively disabling the interface,
-
- - disabling SIP forwarding capability (changing the system from an
- intermediate-system to an end-system),
-
- - setting the Advertise flags of all of the interface's identifiers
- to FALSE.
-
- In such cases, the intermediate-system SHOULD transmit a final
- multicast advertisement on the interface, identical to its previous
- transmission, but with a Lifetime field of zero. In the case of an
- intermediate-system becoming an end-system, the system must also
- depart from the all-routers multicast group on all interfaces on
- which the intermediate-system supports multicast (whether or not they
- had been advertising interfaces).
-
- When the Advertise flag of one or more of an interface's identifiers
- are set to FALSE by system management, but there remain other
- identifiers on that interface whose Advertise flags are TRUE, the
- intermediate-system SHOULD send a single multicast advertisement
- containing only those identifiers whose Advertise flags were set to
- FALSE, with a Lifetime field of zero.
-
- In addition to the periodic unsolicited advertisements, an
- intermediate-system MUST send advertisements in response to valid
- advertisements or solicitations received on any of its advertising
- interfaces. If the advertisement or solicitation does not contain
- any System-Heard extension, and the time since the previous
- advertisement is greater than MAX_INITIAL_ADVERT_INTERVAL, the
- intermediate-system MUST multicast an advertisement from that
- interface.
-
- Whenever these response advertisements are sent, the advertisement
- MUST be delayed for a small random interval not greater than
- MAX_RESPONSE_DELAY, in order to prevent synchronization with other
- responding intermediate-systems, and to allow multiple closely-spaced
- solicitations to be answered with a single advertisement. The
-
-
-
- Simpson expires in six months [Page 19]
- DRAFT system discovery June 1993
-
-
- interface's interval timer is reset to a new random value, as with
- unsolicited advertisements.
-
-
- 4.2.4. Receipt
-
- All systems MUST silently discard any received Intermediate-System
- Advertisement messages that do not satisfy the following validity
- checks:
-
- - ICMP Checksum is correct.
-
- - ICMP length (derived from the payload length) is 16 or more
- octets.
-
- - At least one Routing-Information extension.
-
- - For interfaces which are not point-to-point links, the Media-
- Access extension.
-
-
- 4.3. Processing Advertisements
-
- Every intermediate-system saves the information contained in the
- advertisements, in order to respond to future requests. Any other
- action on receipt of such messages by an intermediate-system (for
- example, as part of a "peer discovery" process) is beyond the scope
- of this document.
-
- An end-system saves the information contained in the advertisements,
- in order to determine the first-hop when sending datagrams. First-
- hop determination is elaborated in a subsequent section.
-
-
- 4.3.1. Configuration
-
- The Host Requirements -- Communication Layers [1], Section 3.3.1.6,
- specifies that each end-system must support a configurable list of
- default intermediate-system identifiers. The purpose of the
- intermediate-system discovery messages is to eliminate the need to
- configure that list. On links for which intermediate-system
- discovery is administratively disabled, it MAY continue to be
- necessary to configure the default intermediate-system list in each
- end-system.
-
- Each entry in the list contains (at least) the following configurable
- variables:
-
-
-
-
- Simpson expires in six months [Page 20]
- DRAFT system discovery June 1993
-
-
- RouterAddress
-
- An identifier of a default intermediate-system.
-
- Default: (none)
-
- PreferenceLevel
-
- The preferability of the RouterAddress as a default intermediate-
- system choice, relative to other intermediate-system interfaces
- serving the same prefix on the same link. The Host Requirements
- RFC does not specify how this value is to be encoded. The values
- used here are defined above.
-
- Default: 255
-
-
- 4.3.2. Implementation
-
- To process an Intermediate-System Advertisement, an end-system scans
- the list of Routing-Information extensions contained in it. For each
- identifier, the end-system does the following:
-
- - If the prefix size is not zero, the identifier and prefix size are
- compared against any identifiers associated with the interface on
- which the message was received. If there is a match, the
- interface prefix size is set to the advertised prefix size.
-
- - If the identifier is not already present in the end-system's
- intermediate-system list, a new entry is added to the list,
- containing the identifier along with its accompanying preference
- level, and a timer initialized to the Lifetime value from the
- advertisement.
-
- - If the identifier is already present in the end-system's
- intermediate-system list as a result of a previously-received
- advertisement, its preference level is updated and its timer is
- reset to the value in the newly-received advertisement.
-
- - If the identifier is already present in the end-system's
- intermediate-system list as a result of system configuration, no
- change is made to its preference level. There is no timer
- associated with a configured identifier.
-
- - If a Media-Access extension is present, the intermediate-system
- list is updated with the location information.
-
- Whenever the timer expires in any entry that was created as a result
-
-
-
- Simpson expires in six months [Page 21]
- DRAFT system discovery June 1993
-
-
- of a received advertisement, that entry is discarded.
-
- Note that any intermediate-system identifiers acquired from the
- "Gateway" subfield of the vendor extensions field of a BOOTP
- packet [11] are considered to be configured identifiers; they are
- assigned the default preference level of 255, and they do not have
- an associated timer.
-
- Note further that any identifier found in the "giaddr" field of a
- BOOTP packet [3] identifies a BOOTP forwarder which is not
- necessarily a SIP intermediate-system; such an identifier should
- not be installed in the end-system's default intermediate-system
- list.
-
- To limit the storage needed for the default intermediate-system list,
- an end-system MAY choose not to store all of the intermediate-system
- identifiers discovered via advertisements. The end-system SHOULD
- discard those identifiers with lower preference levels in favor of
- those with higher levels. It is desirable to retain more than one
- default intermediate-system identifier in the list; if the current
- choice of default intermediate-system is discovered to be down, the
- end-system may immediately choose another default intermediate-system
- without having to wait for the next advertisement to arrive.
-
- Any intermediate-system identifier advertised with a preference level
- of zero is not to be used by the end-system as default intermediate-
- system identifier. Such an identifier may be omitted from the
- default intermediate-system list, unless its timer is being use as a
- "black-hole" detection mechanism.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Simpson expires in six months [Page 22]
- DRAFT system discovery June 1993
-
-
- 5. End-System Discovery
-
- Within a directly attached link, each system must be able to locate
- end-systems with which it desires to communicate. This is
- accomplished using the Where-Are-You and I-Am-Here messages described
- below. This is independent of any specific media.
-
- When an intermediate-system needs the location of an end-system, it
- sends the Where-Are-You solicitation. The target end-system responds
- with the I-Am-Here advertisement.
-
- When no intermediate-system advertisements have been heard, an end-
- system sends the Where-Are-You solicitation itself. The target end-
- system responds with the I-Am-Here advertisement as usual.
-
- When an end-system has heard one or more intermediate-system
- advertisements, the default behavior is to send all datagrams to the
- preferred intermediate-system. If the target end-system is
- accessible on the local link, the intermediate-system sends a
- redirect back indicating the appropriate media address.
-
- When an end-system has heard one or more intermediate-system
- advertisements, and no zone or prefix-routing is being used, or no
- prefix matches any current interface identifier, the end-system can
- assume that it is operating as a mobile end-system. The mobile end-
- system advertises on a periodic basis, just as an intermediate-
- system.
-
-
- 5.1. Solicitations
-
- Every SIP system MUST implement End-System Solicitation for discovery
- of local end-systems.
-
- When a system is ready to send a datagram to another system, it
- examines its cache of system locations. If no intermediate-system
- advertisements have been received, the system MUST send the Where-
- Are-You solicitation to prompt the advertisement of the target
- system.
-
- If (and only if) no advertisements from the target system are
- forthcoming, the system MAY retransmit the Where-Are-You a small
- number of times, but then MUST desist from sending more
- solicitations.
-
-
-
-
-
-
-
- Simpson expires in six months [Page 23]
- DRAFT system discovery June 1993
-
-
- 5.1.1. Implementation
-
- The end-system solicitation is sent to the all-systems multicast.
-
- The end-system solicitations use the same configuration constants as
- intermediate-system solicitations.
-
- Unlike intermediate-system solicitations, end-system solicitations
- are sent only when a particular end-system location is needed, rather
- than on startup.
-
- End-system solicitations are sent using the same periodicity
- calculations as intermediate-system solicitations.
-
- Upon receiving a valid advertisement from any intermediate-system, an
- end-system MUST NOT send any end-system solicitations.
-
-
- 5.1.2. Receipt
-
- An intermediate-system MUST silently discard any received End-System
- Solicitation messages.
-
- An end-system MUST silently discard any received End-System
- Solicitation messages that do not satisfy the following validity
- checks:
-
- - ICMP Checksum is correct.
-
- - ICMP length (derived from the payload length) is 16 or more
- octets.
-
- - Source Address is either 0 or the identifier of a neighbor (an
- identifier that matches one of the end-system's own identifiers on
- the arrival interface under the prefix mask associated with that
- identifer, or the zone associated with that interface).
-
-
- 5.2. Advertisements
-
- Every SIP end-system MUST implement End-System Advertisements.
-
- Usually, end-system advertisements are sent in response to end-system
- solicitations. In addition, mobile end-system advertisements and
- service end-system advertisements (described below) are sent on a
- periodic basis.
-
- The end-system advertisements include such important information as
-
-
-
- Simpson expires in six months [Page 24]
- DRAFT system discovery June 1993
-
-
- the media address to access the system, and neighboring
- intermediate-systems heard.
-
-
- 5.2.1. Implementation
-
- The periodic mobile end-system advertisement is sent to the all-
- routers multicast.
-
- The single end-system advertisement in respnse to a solicitation is
- sent to the all-systems multicast.
-
- In either case, the scope is set to local.
-
- CONTROVERIAL: The all-systems multicast is used for end-system
- advertisements, rather than responding directly to the soliciting
- system. This is under the assumption that all intermediate-
- systems need to update the list of active end-systems, when the
- query is sent by a router. Logically, the response could be sent
- to all-routers.
-
- However, when the query is sent by an end-system, there are no
- routers present. The response could be sent directly to the
- requesting end-system.
-
- There is no easy way to determine that the sender was an
- intermediate-system rather than an end-system. The only multicast
- which covers both cases is all-systems.
-
- Mobile advertisements use similar configuration constants and
- variables as intermediate-system advertisements.
-
- Mobile advertisements are sent using the same periodicity
- calculations as intermediate-system advertisements.
-
- Advertising interfaces are established and terminated in the same
- manner as intermediate-system advertisements.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Simpson expires in six months [Page 25]
- DRAFT system discovery June 1993
-
-
- 6. Service Discovery
-
- Each system offering one of the special configuration services
- detailed below, whether an end-system or intermediate-system,
- includes that service availability in every advertisement that it
- sends. All systems discover the location of these services simply by
- listening for the advertisements. This eliminates the need for
- manual configuration, periodic probes, and special handling of
- certain packet types by intermediate-systems.
-
- The learned service information is included in any neighboring
- intermediate-system advertisements. In this fashion, the
- intermediate-system advertisements provide a summary of all available
- network services, and pass information beyond the link where the
- advertisement originated. This results in a reduction of network
- traffic when compared to the broadcast or multicast of service
- discovery requests/replies over a wide area.
-
- The initial services listed here are primarily concerned with
- configuration. The locations of other facilities may be learned from
- these basic servers.
-
- Domain Name Service
-
- Before a system can communicate with another system, it must learn
- that system's identifiers and location. The Domain Name System
- (DNS) is usually used for this purpose.
-
- In the past, this was accomplished by reading a list of servers
- from a (possibly remote) configuration file at startup time. Some
- systems discovered servers by sending periodic probes to a
- broadcast or multicast address. Both of these methods have
- serious drawbacks. Configuration files must be maintained
- manually (a significant administrative burden when ther are large
- numbers of systems), and are unable to track dynamic changes in
- DNS availability. Periodic probes are restricted from using
- recursion (see Host Requirements -- Application and Support [2],
- Section 6.1.3.2), and are thus limited to information about the
- local domain.
-
- In practice, only systems which are users or stub resolvers of the
- DNS can use the DNS server advertisements. Full-Service resolvers
- MUST continue to be manually configured to ensure a heirarchy of
- believability within the network.
-
- Self-Configuration Service
-
- Before a system can communicate with another system, it must learn
-
-
-
- Simpson expires in six months [Page 26]
- DRAFT system discovery June 1993
-
-
- its own identity. The Bootstrap Protocol (BOOTP) is frequently
- used for this purpose.
-
- In the past, this was accomplished by ad hoc passing of BOOTP
- requests by routers. This method has several serious drawbacks.
- Presence of the feature cannot be relied upon. It is not of much
- use for mobile, roving or portable systems.
-
-
- 6.1. Solicitations
-
- Every SIP end-system SHOULD implement End-System Solicitation for
- discovery of local services.
-
- When a system is ready to use a particular service, it examines its
- cache of such services. If no intermediate-system or other service
- advertisements have been received, the system MAY send the Where-
- Are-You solicitation to prompt the advertisement of the service.
-
- If (and only if) no advertisements from desired services are
- forthcoming, the system MAY retransmit the Where-Are-You a small
- number of times, but then MUST desist from sending more
- solicitations.
-
-
- 6.1.1. Implementation
-
- The service solicitation is sent to the special multicast for each
- particular service, with the scope set to local.
-
- The service solicitations use the same configuration constants as
- intermediate-system and end-system solicitations.
-
- Unlike intermediate-system solicitations, service solicitations are
- sent only when a particular service is utilized, rather than on
- startup.
-
- Service solicitations are sent using the same periodicity
- calculations as intermediate-system and end-system solicitations.
-
- Upon receiving a valid advertisement from any intermediate-system,
- the system MUST NOT send any service solicitation.
-
- Service solicitations require the same validity checks as end-system
- solicitations.
-
-
-
-
-
-
- Simpson expires in six months [Page 27]
- DRAFT system discovery June 1993
-
-
- 6.2. Advertisements
-
- Like intermediate-system and mobile end-system advertisements,
- service end-systems advertisements are sent on a periodic basis.
-
- Services offered by intermediate-systems are included in the
- intermediate-system advertisements described above.
-
-
- 6.2.1. Implementation
-
- The service advertisement is sent to the all-systems multicast, with
- the scope set to local.
-
- CONTROVERIAL: The all-systems multicast is used for service
- advertisements, rather than different multicasts for each service.
- This is under the assumption that all systems need to learn of
- services.
-
- This corresponds to the design for intermediate-system
- advertisements. Thus, intermediate-system advertisements can be
- viewed as a special case of service advertisements.
-
- This ensures that the design will operate when there are no
- routers, and when the routing protocols are still initializing.
-
- The service advertisements use similar configuration constants and
- variables as intermediate-system advertisements.
-
- Service advertisements are sent using the same periodicity
- calculations as intermediate-system advertisements.
-
- Advertising interfaces are established and terminated in the same
- manner as intermediate-system advertisements.
-
- When any system ceases to offer an advertised service, the system
- SHOULD transmit a final multicast advertisement on the interface,
- identical to its previous transmission, but with a Lifetime field of
- zero.
-
-
-
-
-
-
-
-
-
-
-
-
- Simpson expires in six months [Page 28]
- DRAFT system discovery June 1993
-
-
- 7. Self Discovery
-
-
-
- 7.1. End-Systems
-
- At startup, each SIP end-system solicits the advertisements of
- intermediate-systems, as described in Intermediate-System Discovery
- above. Until an intermediate-system is discovered, an end-system is
- limited to accessing systems and services for the links to which it
- is directly attached.
-
- In the absence of an intermediate-system, each SIP end-system
- solicits the advertisements of services as described in Service
- Discovery above. Until self-configuration services are discovered,
- an end-system is limited to accessing systems and services according
- to prior configuration.
-
-
- 7.1.1. Zone Determination
-
- Until an intermediate-system is discovered, an end-system assumes a
- zone number of zero. When combined with any IEEE-802 number found in
- the machine, or other identifier negotiated at the link level, this
- yields a local identifier which is unique to the system.
-
- When an intermediate-system is discovered, the advertisements are
- examined for zone information, as described in Intermediate-System
- Discovery above. If all advertised zone values are zero, then zone
- routing is not available beyond that link. If more than one zone
- number is discovered for the same interface, only the highest zone
- number is used.
-
- When there is more than one interface on a multi-homed end-system,
- each interface MUST answer to all of the local identifers generated.
-
- When more than one IEEE-802 number is available, the primary system
- identifier is composed of the highest zone discovered, combined with
- the highest IEEE-802 number found.
-
-
- 7.1.2. Initialization
-
- Once a system has becomed locally addressable, it can engage in
- exchanges with local servers. Some of these local servers could be a
- bootstrap service, for loading and configuring the system. Another
- server could be a registration service, in charge of managing the
- local name and identifier space.
-
-
-
- Simpson expires in six months [Page 29]
- DRAFT system discovery June 1993
-
-
- When the registration service is unable to find a match for the
- system, the system SHOULD request the operator to provide a name for
- the system. The registration service would be responsible for
- ensuring uniqueness, and assigning appropriate identifiers for the
- name.
-
- Further specification of such services is beyond the scope of this
- document.
-
-
- 7.1.3. Identifier Determination
-
- Once the Domain Name has been determined for a system, the Domain
- Name Service SHOULD be consulted to determine the globally advertised
- identifiers for the system. In this fashion, system is coordinated
- with the most current information actually propagated within the
- internet.
-
- Each DNS identifier has a Time-To-Live associated with it. When any
- identifier expires, another request SHOULD be made to the DNS for a
- list of identifiers.
-
- When there is more than one interface on a multi-homed end-system,
- each interface MUST answer to all of the identifers learned.
-
- When more than one identifier is returned for a system, the primary
- system identifier is the identifier with the highest TTL, or the
- first listed identifier of those with the highest TTL.
-
-
- 7.1.4. Prefix Determination
-
- The prefix size is dynamically learned from matching interface
- identifiers against the intermediate-system advertisements, as
- described in Intermediate-System Discovery above.
-
- Unlike previous practice, an end-system prefix sizes SHOULD NOT be
- preconfigured. Any preconfigured value MUST be superceded by new
- values and changes propagated in intermediate-system advertisements.
-
-
- 7.1.5. Changing Identifiers
-
-
-
- 7.2. Intermediate-Systems
-
- The zones and prefixes are assigned by hand.
-
-
-
- Simpson expires in six months [Page 30]
- DRAFT system discovery June 1993
-
-
- 8. Next-Hop Determination
-
- When an end-system has not heard any intermediate-system
- advertisements, it is assumed that all end-systems are only
- accessible on the local link.
-
- multi-homed
-
- preferred router
-
- smart selection
-
- local redirect
-
- remote redirect
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Simpson expires in six months [Page 31]
- DRAFT system discovery June 1993
-
-
- 8.1. Examples of Use
-
- Simple case -- J to K on the same fully-connected link.
-
- J sends the Where-Are-You (which contains its own media address)
- to all-systems. K sends the I-Am-Here (which contains its own
- media address) directly to all-systems. At this point, they
- both know that they can talk directly to each other, without
- regard to subnet.
-
- Routed case -- J to K not on the same fully-connected link.
-
- If no resource reservation or policy routing is desired, J
- simply sends its packets directly to the "preferred" router that
- it has learned from the Advertisements. If there is a better
- router for the first-hop, that router sends the I-Am-Here
- redirect to J, but never-the-less forwards the packet.
-
- In the presence of RR or PR, J sends a Where-Are-You to the
- "preferred" router that it has learned from the Advertisements.
- That router always returns an I-Am-Here redirect (even if the
- correct hop is itself), which contains the requested RR or PR
- status information. J then sends its packets to the first-hop
- router as determined from the I-Am-Here.
-
- General case -- J to K over disconnected partial mesh (radio/framerelay).
-
- J periodically sends the I-Am-Here (which contains its own media
- address, and the addresses of its "heard" routers) to the
- all-routers multicast. The routers use such messages to
- construct a map of the current state of the topology. The
- routers now know who J hears, and who hears J.
-
- If the routing map doesn't contain a current whereabouts of K,
- the Destination Unreachable message is returned by the "best"
- router on J's "heard" list.
-
- If the routing map contains the current whereabouts of K, the
- "best" router on K's "heard" list sends a Where-Are-You to K,
- with a list of routers which can hear K. The list is ordered by
- the intersection of those routers which can also hear J,
- minimizing the number of hops.
-
- When K hears the Where-Are-You, it sends the I-Am-Here to the
- all-systems address. The "best" router on J's "heard" list
- sends an I-Am-Here redirect to J, with a substitute list of
- routers which can hear J. The list is ordered by the
- intersection of those routers which can also hear K.
-
-
-
- Simpson expires in six months [Page 32]
- DRAFT system discovery June 1993
-
-
- Of course, J may have heard K's I-Am-Here directly.
-
- At this point, the routing fabric knows which routers are heard
- by J and K, and which routers can hear J and K. J and K know
- whether they can hear each other directly. If not, they know
- the "best" next-hop router (which may not be the same in both
- directions).
-
- Unlike the fully-connected scenarios, this scheme requires that
- the I-Am-Here is sent from time to time to keep the map updated.
- However, only routers need store the information.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Simpson expires in six months [Page 33]
- DRAFT system discovery June 1993
-
-
- 9. Additional ICMP Packets
-
- The Packet format and basic facilities are already defined for ICMP
- [3], as modified for SIP [1].
-
- Up-to-date values of the ICMP Type field are specified in the most
- recent "Assigned Numbers" RFC [2]. This document concerns the
- following values:
-
- <TBD> Where-Are-You
- <TBD> I-Am-Here
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Simpson expires in six months [Page 34]
- DRAFT system discovery June 1993
-
-
- 9.1. Where-Are-You
-
- A summary of the Where-Are-You message format is shown below. The
- fields are transmitted from left to right.
-
- 0 1 2 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Type | Code | Checksum |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Reserved |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | |
- + System Identifier +
- | |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Extensions ...
- +-+-+-+-+-+-+-+-+-+-+-+-+
-
-
- Type
-
- <TBD>
-
- Code
-
- The Code field is one octet. Up-to-date values of the I-Am-Here
- Code field are specified in the most recent "Assigned Numbers" RFC
- [2]. Current values are assigned as follows:
-
- 0 RESERVED
- 1 End-System Solicitation
- 2 Intermediate-System Solicitation
-
-
- Checksum
-
- The ICMP Checksum.
-
- System Identifier
-
- The System Identifier field is eight octets in length, and
- contains an identifier of the system which is sought. When the
- identifer of the system is unknown, the field is zero filled.
-
- Extensions
-
- The Extensions field is variable in length and contains zero or
-
-
-
- Simpson expires in six months [Page 35]
- DRAFT system discovery June 1993
-
-
- more Extensions. These Extensions are described in a later
- section.
-
- The contents of the Reserved field are ignored. Future backward-
- compatible changes to the protocol may specify the contents of the
- Reserved field or of additional octets at the end of the message.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Simpson expires in six months [Page 36]
- DRAFT system discovery June 1993
-
-
- 9.1.1. End-System Solicitation
-
- The End-System Solicitation contains the following values:
-
- - In the Destination Address field of the SIP header: For service
- solicitations, the special multicast group associated with the
- service. For other solicitations, the all-systems multicast. In
- either case, the scope is set to local.
-
- - In the Source Address field of the SIP header: any identifier
- associated with the sending interface. It MAY contain zero if the
- system has not yet determined an identifier for the interface.
-
- - In the Code field of the ICMP header: 1 for End-System
- Solicitation.
-
- - For each intermediate-system advertisement that has been heard,
- the System-Heard extension.
-
- - For interfaces which are not point-to-point links, the Media-
- Access extension.
-
- In the unlikely event that not all extensions fit in a single
- solicitaion, as constrained by the MTU of the link, the remaining
- extensions are removed. Only a single solicitation is sent.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Simpson expires in six months [Page 37]
- DRAFT system discovery June 1993
-
-
- 9.1.2. Intermediate-System Solicitation
-
- The Intermediate-System Solicitation contains the following values:
-
- - In the Destination Address field of the SIP header: the all-
- routers multicast, with the scope set to local.
-
- - In the Source Address field of the SIP header: any identifier
- associated with the sending interface. It MAY contain zero if the
- system has not yet determined an identifier for the interface.
-
- - In the Code field of the ICMP header: 2 for Intermediate-System
- Solicitation.
-
- - For each of that system's interface identifiers other than the
- primary identifier, the Other-Identifier extension, with the
- prefix size set to zero.
-
- - For each intermediate-system advertisement that has been heard,
- the System-Heard extension.
-
- - For interfaces which are not point-to-point links, the Media-
- Access extension.
-
- In the unlikely event that not all extensions fit in a single
- solicitaion, as constrained by the MTU of the link, multiple
- solicitations are sent, with each except the last containing as many
- extensions as can fit.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Simpson expires in six months [Page 38]
- DRAFT system discovery June 1993
-
-
- 9.2. I-Am-Here
-
- A summary of the I-Am-Here message format is shown below. The fields
- are transmitted from left to right.
-
- 0 1 2 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Type | Code | Checksum |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Sequence Number | LifeTime |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | |
- + System Identifier +
- | |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Extensions ...
- +-+-+-+-+-+-+-+-+-+-+-+-+
-
-
- Type
-
- <TBD>
-
- Code
-
- The Code field is one octet. Up-to-date values of the I-Am-Here
- Code field are specified in the most recent "Assigned Numbers" RFC
- [2]. Current values are assigned as follows:
-
- 0 RESERVED
- 1 End-System Advertisement
- 2 Intermediate-System Advertisement
- 3 Local Redirect
- 4 Remote Redirect
-
-
- Checksum
-
- The ICMP Checksum.
-
- Sequence Number
-
- The Sequence Number field is two octets in length, and contains
- the number of I-Am-Here messsages sent since the system was
- initialized. This number MUST include this advertisement.
-
-
-
-
-
- Simpson expires in six months [Page 39]
- DRAFT system discovery June 1993
-
-
- LifeTime
-
- The LifeTime field is two octets in length, and indicates the
- seconds remaining before the entry is considered invalid.
-
- System Identifier
-
- The System Identifier field is eight octets in length, and
- contains the primary identifier for this system. Other
- identifiers are indicated with the Other-Identifier extension.
-
- Extensions
-
- The Extensions field is variable in length and contains zero or
- more Extensions. These Extensions are described in a later
- section.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Simpson expires in six months [Page 40]
- DRAFT system discovery June 1993
-
-
- 9.2.1. End-System Advertisement
-
- The End-System Advertisement contains the following values:
-
- - In the Destination Address field of the SIP header: For periodic
- mobile end-system advertisements, the all-routers multicast. For
- other end-system advertisements, the all-systems multicast. In
- either case, the scope is set to local.
-
- - In the Source Address field of the SIP header: For service
- advertisements, the primary identifier associated with that
- system. For responses to solicitations, the identifier specified
- in the solicitation.
-
- - In the Code field of the ICMP header: 1 for End-System
- Advertisement.
-
- - In the Lifetime field: the interface's configured
- AdvertisementLifetime.
-
- - For each of that system's interface identifiers other than the
- primary identifier, the Other-Identifier extension, with the
- prefix size set to zero.
-
- - For each service advertisement that is offered, the Service-
- Information extension.
-
- - For each intermediate-system advertisement that has been heard,
- the System-Heard extension.
-
- - For interfaces which are not point-to-point links, the Media-
- Access extension.
-
- In the unlikely event that not all extensions fit in a single
- advertisement, as constrained by the MTU of the link, multiple
- advertisements are sent, with each except the last containing as many
- extensions as can fit.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Simpson expires in six months [Page 41]
- DRAFT system discovery June 1993
-
-
- 9.2.2. Intermediate-System Advertisement
-
- The Intermediate-System Advertisement contains the following values:
-
- - In the Destination Address field of the SIP header: the all-
- systems multicast, with the scope set to local.
-
- - In the Source Address field of the SIP header: the primary
- identifier of the system. The same identifier is used for all
- interfaces.
-
- - In the Code field of the ICMP header: 2 for Intermediate-System
- Advertisement.
-
- - In the Lifetime field: the interface's configured
- AdvertisementLifetime.
-
- - For each of that interface's identifiers whose Advertise flags are
- TRUE, the Routing-Information extension.
-
- - For each of that interface's recently changed identifiers, the
- Change-Identifier extension.
-
- - For each of that system's other interface's identifiers which have
- not already been included through prefix subsumption, the Other-
- Identifier extension.
-
- - For each service that is offered, or has been learned from another
- advertisement, the Service-Information extension.
-
- - For each intermediate-system advertisement that has been heard,
- the System-Heard extension.
-
- - For interfaces which are not point-to-point links, the Media-
- Access extension.
-
- In the unlikely event that not all extensions fit in a single
- advertisement, as constrained by the MTU of the link, multiple
- advertisements are sent, with each except the last containing as many
- extensions as can fit.
-
-
-
-
-
-
-
-
-
-
-
- Simpson expires in six months [Page 42]
- DRAFT system discovery June 1993
-
-
- 10. Extensions
-
- Extensions allow variable amounts of information to be carried within
- each Advertisement or Advertisement packet. Some extensions are
- common to both packet types.
-
- The end of the list of Extensions is indicated by the Payload Length
- of the SIP packet.
-
- A summary of the Extensions format is shown below. The fields are
- transmitted from left to right.
-
- 0 1
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Type | Length | Data ...
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-
- Type
-
- The Type field is one octet and indicates the type of Extension.
- Up-to-date values of the Extension Type field are specified in the
- most recent "Assigned Numbers" RFC [2]. Current values are
- assigned as follows:
-
- 1 Media-Access
- 2 Change-Identifier
- 3 Other-Identifier
- 4 System-Heard
- 5 Routing-Information
- 6 Service-Information
- 7 Transit-Information
- 8 Authentication
- 9 Security-Information
- 10 Redirected-Header
-
-
- Length
-
- The Length field is one octet and indicates the length of the Data
- field which has been used.
-
- Each Extension ends on an octet boundary which is an integral
- multiple of four octets. Any unused portion of the Data field is
- padded with zeros.
-
-
-
-
-
- Simpson expires in six months [Page 43]
- DRAFT system discovery June 1993
-
-
-
- length actual
- 0 through 2 4
- 3 through 6 8
- 7 through 10 12
-
-
- Data
-
- The Data field is zero or more octets and contains the value or
- other information for this Extension. The format and length of
- the Data field is determined by the Type and Length fields.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Simpson expires in six months [Page 44]
- DRAFT system discovery June 1993
-
-
- 10.1. Media-Access
-
- A summary of the Media-Access extension format is shown below. The
- fields are transmitted from left to right.
-
- 0 1 2 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Type | Length | Media Type |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | MAC Address ...
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-
- Type
-
- 1
-
- Length
-
- >= 3
-
- Media Type
-
- The Media Type field is two octets in length. The value of this
- field is the same as the Hardware Type used in ARP. Up-to-date
- values of the Hardware Type field are specified in the most recent
- "Assigned Numbers" RFC [2].
-
- [Should we use the ifType from MIB-II instead?]
-
- MAC Address
-
- The MAC Address field is variable in length, and contains the media
- address which is used to access this system.
-
- The MAC Address is always specified in Canonical order.
-
- The Media-Access extension MUST be included in those messages sent from
- an interface on a multi-access media.
-
- It MUST NOT be included in a message sent from a point-to-point
- interface, or in messages such as the Remote Redirect which pass through
- intermediate systems.
-
-
-
-
-
-
-
- Simpson expires in six months [Page 45]
- DRAFT system discovery June 1993
-
-
- 10.2. Change-Identifier
-
- A summary of the Change-Identifier extension format is shown below. The
- fields are transmitted from left to right.
-
- 0 1 2 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Type | Length | |Prefix Size|
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | |
- + Old Identifier +
- | |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | |
- + New Identifier +
- | |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-
- Type
-
- 2
-
- Length
-
- 22
-
- Prefix Size
-
- The Prefix Size field is six bits in length, and indicates the number
- of bits in both Identifiers which define the prefix mask for the
- link. The value ranges from 0 to 62.
-
- End-Systems MUST have a Prefix Size of zero.
-
- Old Identifier
-
- The Old Identifier field is eight octets in length, and contains the
- old identifier for this interface.
-
- New Identifier
-
- The New Identifier field is eight octets in length, and contains one
- of the identifiers for this interface. This may be another
- identifier for the same interface that sent the message, or may
-
-
-
- Simpson expires in six months [Page 46]
- DRAFT system discovery June 1993
-
-
- identify another interface on the same system which sent the message.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Simpson expires in six months [Page 47]
- DRAFT system discovery June 1993
-
-
- 10.3. Other-Identifier
-
- A summary of the Other-Identifier extension format is shown below. The
- fields are transmitted from left to right.
-
- 0 1 2 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Type | Length | |Prefix Size|
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Metric |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | |
- + Interface Identifier +
- | |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-
- Type
-
- 3
-
- Length
-
- 14
-
- Prefix Size
-
- The Prefix Size field is six bits in length, and indicates the number
- of bits in the Interface Identifier which define the prefix mask for
- the link. The value ranges from 0 to 62.
-
- If the Interface Identifier does not indicate a valid prefix, the
- value is zero.
-
- End-Systems MUST have a Prefix Size of zero.
-
- Metric
-
- The Metric field is four octets in length, and indicates the
- preference level for use of this system to forward packets to the
- Interface Identifier. Lower values indicate greater preference.
-
- End-Systems MUST set this field to zero.
-
- Interface Identifier
-
- The Interface Identifier field is eight octets in length, and
-
-
-
- Simpson expires in six months [Page 48]
- DRAFT system discovery June 1993
-
-
- contains one of the identifiers for this system. This may be another
- identifier for the same interface that sent the message, or may
- identify another interface on the same system which sent the message.
-
- Every identifier for every interface is listed in each I-Am-Here
- message.
-
- This supports multiple identifiers per interface, as well as multi-homed
- systems.
-
- When a number of interfaces, such as point-to-point interfaces, may be
- aggregated with the same prefix, only one extension need be included.
-
- This enables end-systems to determine the best next-hop without sending
- a Where-Are-You solicitation when the next-hop is on another interface
- attached to the same advertising system.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Simpson expires in six months [Page 49]
- DRAFT system discovery June 1993
-
-
- 10.4. System-Heard
-
- A summary of the System-Heard extension format is shown below. The
- fields are transmitted from left to right.
-
- 0 1 2 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Type | Length | Speed |D|B|Prefix Size|
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | MRU | |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | |
- + System Identifier +
- | |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Sequence Number | Remaining LifeTime |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Quality |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Advertisement Count |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Error Count |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-
- Type
-
- 4
-
- Length
-
- 30
-
- Designated Bit
-
- The Designated Bit indicates that the System Identifier is the
- Designated Router.
-
- Backup Bit
-
- The Backup Bit indicates that the System Identifier is the Backup
- Designated Router.
-
- Prefix Size
-
- The Prefix Size field is six bits in length, and indicates the number
- of bits in the System Identifier which define the prefix mask for the
-
-
-
- Simpson expires in six months [Page 50]
- DRAFT system discovery June 1993
-
-
- link. The value ranges from 0 to 62.
-
- If the System Identifier does not indicate a valid prefix, the value
- is zero.
-
- End-Systems MUST have a Prefix Size of zero.
-
- MRU
-
- The Maximum Receive Unit field is two octets in length, and indicates
- the maximum size packet that the system will receive over the link.
-
- Speed
-
- The Speed field is one octet in length, and indicates the speed of
- the link over which the advertisement or solicitation was heard.
- Higher values indicate greater speed. The speed value is related to
- int( 10 * ln( speed / 100 ) ) in bits per second.
-
- After considerable trial and error, this formula was used because
- it gave the best distribution for distinguishing medium speed
- links, and fit reasonably well in the realm of currently
- envisioned speeds. It has an upper limit of 11.87 Terabits per
- second. (It also has a convenient button on the calculator.)
-
- 0 link is down
- 1 - 9 reserved
- 10 300 or less
- 24 1,200 96 1,544,000 T1
- 31 2,400 99 2,048,000 E1
- 38 4,800 106 4,000,000 Token Ring
- 42 7,200 110 6,312,000 T2
- 45 9,600 115 10,000,000 Ethernet
- 49 14,400 119 16,000,000 Token Ring
- 52 19,200
- 56 28,800 130 44,736,000 T3
- 59 38,400 142 155,520,000 STS-3,STM-1
- 63 57,600 202 622,080,000 STS-12,STM-4
- 64 64,000 216 2,488,320,000 STS-48,STM-16
- 71 128,000
- 73 153,600
- 78 256,000
-
-
- System Identifier
-
- The System Identifier field is eight octets in length, and contains
- the primary identifier for the system, taken from the Source Address
-
-
-
- Simpson expires in six months [Page 51]
- DRAFT system discovery June 1993
-
-
- field of the advertisement heard.
-
- Sequence Number
-
- The Sequence Number field is two octets in length, and contains the
- last heard sequence number from the system.
-
- Remaining LifeTime
-
- The Remaining LifeTime field is two octets in length, and indicates
- the seconds remaining before the entry is considered invalid.
-
- Quality
-
- The Quality field is four octets in length, and contains an
- indication of the signal quality received from this system. Higher
- values indicate greater quality.
-
- Advertisement Count
-
- The Advertisement Count field is four octets in length, and indicates
- the number of advertisements that have been heard from the identified
- system.
-
- Error Count
-
- The Error Count field is four octets in length, and indicates the
- number of errors which have been detected on the link with the
- identified system.
-
- This extension is included in every I-Am-Here.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Simpson expires in six months [Page 52]
- DRAFT system discovery June 1993
-
-
- 10.5. Routing-Information
-
- A summary of the Routing-Information extension format is shown below.
- The fields are transmitted from left to right.
-
- 0 1 2 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Type | Length | Preference |D|B|Prefix Size|
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | MRU | Zone | Priority |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | |
- + Interface Identifier +
- | |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-
- Type
-
- 5
-
- Length
-
- 14
-
- Preference
-
- The Preference field is one octet in length, and indicates the
- preference level for use of this system to forward packets to the
- Interface Identifier. Higher values indicate greater preference.
-
- Designated Bit
-
- The Designated Bit indicates that the system is the Designated
- Router.
-
- Backup Bit
-
- The Backup Bit indicates that the system is the Backup Designated
- Router.
-
- Prefix Size
-
- The Prefix Size field is six bits in length, and indicates the number
- of bits in the Interface Identifier which define the prefix mask for
- the link. The value ranges from 0 to 62.
-
-
-
-
- Simpson expires in six months [Page 53]
- DRAFT system discovery June 1993
-
-
- If the Interface Identifier does not indicate a valid prefix, the
- value is zero.
-
- MRU
-
- The Maximum Receive Unit field is two octets in length, and indicates
- the maximum size packet that the system will receive over the link.
-
- Zone
-
- The Zone field is one octet in length, and indicates the zone for the
- link. A value of zero indicates that no zone has been assigned.
-
- Priority
-
- The Priority field is one octet in length, and indicates the priority
- for election to Designated Backup. A value of zero indicates that
- the system is not eligible.
-
- Interface Identifier
-
- The Interface Identifier field is eight octets in length, and
- contains one of the identifiers for this interface.
-
- This extension is sent only by Intermediate-Systems.
-
- When more than one of these extensions is present, the Designated and
- Backup bits, MRU, Zone and Priority fields MUST be the same in each
- copy.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Simpson expires in six months [Page 54]
- DRAFT system discovery June 1993
-
-
- 10.6. Service-Information
-
- A summary of the Service-Information extension format is shown below.
- The fields are transmitted from left to right.
-
- 0 1 2 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Type | Length | Service |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Sequence Number | Remaining LifeTime |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | |
- + System Identifier +
- | |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Data ...
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-
- Type
-
- 6
-
- Length
-
- >= 14
-
- Service
-
- The Service field is two octets in length. The value of this field
- is usually the same as the well-known port number. Up-to-date values
- of the Service field are specified in the most recent "Assigned
- Numbers" RFC [2].
-
- Sequence Number
-
- The Sequence Number field is two octets in length, and contains the
- last heard sequence number from the system.
-
- Remaining LifeTime
-
- The Remaining LifeTime field is two octets in length, and indicates
- the seconds remaining before the entry is considered invalid.
-
- System Identifier
-
- The System Identifier field is eight octets in length, and contains
-
-
-
- Simpson expires in six months [Page 55]
- DRAFT system discovery June 1993
-
-
- the primary identifier for this system.
-
- Data
-
- The Data field is variable in length, and contains information
- specific to the service. For example, it could contain a string with
- the description of the service.
-
- The format of the Data field is entirely service dependent, and is
- always treated as a binary value.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Simpson expires in six months [Page 56]
- DRAFT system discovery June 1993
-
-
- 10.7. Transit-Information
-
- A summary of the Transit-Information extension format is shown below.
- The fields are transmitted from left to right.
-
- 0 1 2 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Type | Length | | QoS |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Metric |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-
- Type
-
- 7
-
- Length
-
- 6
-
- QoS
-
- The Quality of Service field is one octet in length, and indicates a
- service for which transit will be accepted.
-
- Metric
-
- The Metric field is four octets in length, and indicates the
- preference level for use of this network link to forward packets of
- the indicated Quality of Service. Lower values indicate greater
- preference.
-
- This extension is included in the Intermediate-System I-Am-Here to
- indicate that it will accept transit traffic. If this extension is not
- included, other intermediate-systems will treat the link as a stub
- network.
-
-
-
-
-
-
-
-
-
-
-
-
-
- Simpson expires in six months [Page 57]
- DRAFT system discovery June 1993
-
-
- 10.8. Authentication
-
- A summary of the Authentication extension format is shown below. The
- fields are transmitted from left to right.
-
- 0 1 2 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Type | Length | |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Data ...
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-
- Type
-
- 8
-
- Length
-
- 22
-
- Data
-
- The Data field is variable in length, and contains information
- specific to the authentication method,
-
-
- This extension is included in any I-Am-Here.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Simpson expires in six months [Page 58]
- DRAFT system discovery June 1993
-
-
- 10.9. Security-Information
-
- A summary of the Security-Information extension format is shown below.
- The fields are transmitted from left to right.
-
- 0 1 2 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Type | Length | |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Compartments ...
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-
- Type
-
- 9
-
- Length
-
- 22
-
- Compartments
-
- The Compartments field is sixteen octets in length.
-
- This extension is included in the Intermediate-System I-Am-Here to
- indicate that it will accept transit traffic for the designated security
- compartments.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Simpson expires in six months [Page 59]
- DRAFT system discovery June 1993
-
-
- 10.10. Redirected-Header
-
- A summary of the Redirected-Header extension format is shown below. The
- fields are transmitted from left to right.
-
- 0 1 2 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Type | Length | |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | SIP Header ...
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-
- Type
-
- 10
-
- Length
-
- 22
-
- SIP Header
-
- The SIP Header field is 48 octets in length.
-
- This extension is included in the Local or Remote Redirect to verifiy
- the traffic that is being redirected.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Simpson expires in six months [Page 60]
- DRAFT system discovery June 1993
-
-
- Security Considerations
-
-
-
- References
-
- [1]
-
- [2]
-
-
- Acknowledgments
-
-
-
- Chair's Address
-
- The working group can be contacted via the current chairs:
-
-
-
-
-
- Author's Address
-
- Questions about this memo can also be directed to:
-
- William Allen Simpson
- Daydreamer
- Computer Systems Consulting Services
- P O Box 6205
- East Lansing, MI 48826-6205
-
- EMail: Bill.Simpson@um.cc.umich.edu
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Simpson expires in six months [Page 61]
- DRAFT system discovery June 1993
-
-
- Table of Contents
-
-
- 1. Terminology ........................................... 1
-
- 2. Criteria .............................................. 2
-
- 3. Design Overview ....................................... 8
- 3.1 System Identification ........................... 9
- 3.2 Multicast Support ............................... 10
-
- 4. Intermediate-System Discovery ......................... 11
- 4.1 Solicitations ................................... 11
- 4.1.1 Constants ....................................... 12
- 4.1.2 Implementation .................................. 12
- 4.1.3 Receipt ......................................... 13
- 4.2 Advertisements .................................. 13
- 4.2.1 Constants ....................................... 15
- 4.2.2 Configuration ................................... 15
- 4.2.3 Implementation .................................. 17
- 4.2.4 Receipt ......................................... 20
- 4.3 Processing Advertisements ....................... 20
- 4.3.1 Configuration ................................... 20
- 4.3.2 Implementation .................................. 21
-
- 5. End-System Discovery .................................. 23
- 5.1 Solicitations ................................... 23
- 5.1.1 Implementation .................................. 24
- 5.1.2 Receipt ......................................... 24
- 5.2 Advertisements .................................. 24
- 5.2.1 Implementation .................................. 25
-
- 6. Service Discovery ..................................... 26
- 6.1 Solicitations ................................... 27
- 6.1.1 Implementation .................................. 27
- 6.2 Advertisements .................................. 28
- 6.2.1 Implementation .................................. 28
-
- 7. Self Discovery ........................................ 29
- 7.1 End-Systems ..................................... 29
- 7.1.1 Zone Determination .............................. 29
- 7.1.2 Initialization .................................. 29
- 7.1.3 Identifier Determination ........................ 30
- 7.1.4 Prefix Determination ............................ 30
- 7.1.5 Changing Identifiers ............................ 30
- 7.2 Intermediate-Systems ............................ 30
-
- 8. Next-Hop Determination ................................ 31
-
-
-
- Simpson expires in six months [Page ii]
- DRAFT system discovery June 1993
-
-
- 8.1 Examples of Use ................................. 32
-
- 9. Additional ICMP Packets ............................... 34
- 9.1 Where-Are-You ................................... 35
- 9.1.1 End-System Solicitation ......................... 37
- 9.1.2 Intermediate-System Solicitation ................ 38
- 9.2 I-Am-Here ....................................... 39
- 9.2.1 End-System Advertisement ........................ 41
- 9.2.2 Intermediate-System Advertisement ............... 42
-
- 10. Extensions ............................................ 43
- 10.1 Media-Access .................................... 45
- 10.2 Change-Identifier ............................... 46
- 10.3 Other-Identifier ................................ 48
- 10.4 System-Heard .................................... 50
- 10.5 Routing-Information ............................. 53
- 10.6 Service-Information ............................. 55
- 10.7 Transit-Information ............................. 57
- 10.8 Authentication .................................. 58
- 10.9 Security-Information ............................ 59
- 10.10 Redirected-Header ............................... 60
-
- SECURITY CONSIDERATIONS ...................................... 61
-
- REFERENCES ................................................... 61
-
- ACKNOWLEDGEMENTS ............................................. 61
-
- CHAIR'S ADDRESS .............................................. 61
-
- AUTHOR'S ADDRESS ............................................. 61
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-